Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000064_owner-urn-ietf _Wed Nov 6 10:43:47 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12738 for urn-ietf-out; Wed, 6 Nov 1996 10:43:47 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12733 for <[e-mail]>; Wed, 6 Nov 1996 10:43:45 -0500
Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA10431  (mail destined for [e-mail]); Wed, 6 Nov 96 10:43:39 -0500
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
          id KAA07371; Wed, 6 Nov 1996 10:42:18 -0500 (EST)
Message-Id: <[e-mail]>
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Martin J Duerst <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [URN] I18N does not belong in URNs
In-Reply-To: Your message of "Wed, 06 Nov 1996 11:44:05 +0100."
             <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch>
Date: Wed, 06 Nov 1996 10:42:18 -0500
Sender: [e-mail]
Precedence: bulk
Reply-To: Keith Moore <[e-mail]>
Errors-To: [e-mail]

> >That's not true.  People regularly transcribe telephone numbers,
> >email addresses, ISBNs, URLs, credit card numbers, etc. with
> >sufficient accuracy for their purposes.  But ask people to
> >transcribe identifiers in (say) Klingon, or to type them in
> >on a keyboard not designed for such, and you'll get much lower
> >accuracy.
>
> Most telephone numbers of companies are meaningful.

Really? I don't find that to be true in practice.  Looking
through my personal phone book, only two out of thirty-one
business phone numbers had any string or substring I could
recognize as meaningful.

> Most
> email addresses are meaningful. Many URLs are meaningful.
> Transcribability is aided by meaninfulness; there is a smaller
> chance to make a mistake if one of these things is meaninful
> than without meaningfulness.

Yes.  But long-term persistance is damaged by meaningfulness.

> And Klingon is a VERY bad example. Nobody speaks Klingon.
> Nobody grew up with Klingon. Nobody learned Klingon in
> school as we learn the Latin script, and others learn
> their traditional scripts. And Klingon isn't even in
> Unicode. Klingon is a fancy of some SF enthusiasts,
> and not a script used by millions every day to express
> and exchange their thoughts and feelings.

It's not a perfect example.  I picked it because it is
a foreign language to nearly everybody.

> >> Your
> >> last point would have merit were it not that we absolutely must
> >> be able to grandfather in existing name spaces.
> >
> >Yes, we must be able to grandfather existing name spaces *that serve
> >similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
> >Usenet message-ids qualify.  But URNs don't have to handle existing
> >name spaces that don't have the characteristics that URNs have.
> >Offhand, I don't know of any name spaces that have such characteristics,
> >that attempt to be human friendly.
>
> ISBNs don't qualify. They are not persistent.

My understanding is that they're supposed to be persistent,
though they are not always so in practice because some countries
have too-little ISBN space so they must reassign them.

> And the fact that you
> don't know about any such namespaces doesn't guarantee that there
> are no such namespaces.

No, it doesn't.

> About 30 years ago, some people said "I don't know of anybody
> that would want to use anything else than English on computers".
> And then they went on to design protocols :-(.
>
>
> >> We should be building the big tent that everyone can live under,
> >> not trying to close out name spaces we don't like.
> >
> >Yes, and we should also be restricting the problem to something that has
> >a hope of a reasonable solution.  They're not mutually exclusive, but
> >over-reliance on the "one big tent" theory has caused the failure of
> >many protocols.
> >
> >(Please note that assuming we can define I18N'ed URLs -- and there is
> >certainly a better case to be made for these then I18N'ed URNs -- I
> >would have no problem with this group defining resolution protocols that
> >can be used with them.  It's just that I18N isn't appropriate for the
> >URN name-space.  And I18N'ed URLs aren't in scope for this group.)
>
> When I participated in several attempts and discussions to
> internationalize URLs, I was told by several people that have
> also shown up on this list that for URLs, i18n would be difficult,
> but that it would be solved for URNs.

People had different understandings of what URNs are for.

> I definitely hate to see i18n just being moved around and delayed
> by some people. With UTF-8 in URNs, we have made great progress.

No, this is a big step backward.  Just because there is a new layer
being defined doesn't mean that I18N belongs there.

I18N *is* important  -- and I'd be happy to see a draft document or
draft charter for a working group to define a protocol (say an extension
of http/html) to resolve human-friendly names into URNs or URLs.

> Some protocols (notably FTP) are also going in the direction of
> UTF-8. Ideally, we will have a uniform solution for both URLs
> and URNs, based on UTF-8.

No.  Ideally, if we figure out how to do this, we will have a
uniform solution for all URLs.  I18N (and even E8H :) absolutely
doesn't belong in URNs.

> For URNs, it will be by design, for
> URLs, it will be more by retrofitting, because according to
> the URL syntax document, the individual schemes have full
> autonomy.

For URNs, human-friendliness will be excluded by design.

Keith